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DETAILED ACTION 

This action is responsive to communications dated 04/28/04 in response to the 
Restriction Requirement listing Inventions l-lll. Applicants elect without traverse to 
prosecute the claims 5-10 and 14-18 of Invention II. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hackbarth (Helge Hackbarth, "Tiffy View Java Edition", Copyright 1998, downloaded 
from http://web.archive.org/web/19991 106083855/http://www.tiffy.de/tiffye/Tiffy.html) in 
view of Microsoft Press ("Microsoft Press Computer Dictionary, 3 rd Edition", Copyright 
1997 Microsoft Press). 

In regard to independent Claim 5, Hackbarth teaches a platform independent 
application (written in Java) to view and print images of the following formats: TIFF, 
BMP, GIF, JPG, and PNG (called Tiffy View). Additionally, Hackbarth teaches that it is 
usable as a standalone application or, alternatively the program can be run as a Java 
applet in any Java capable web browser to extend standard internet/intranet technology 
with a powerful component for electronic document management (see page 1). The 
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figure located at the top of Page 2 of Hackbarth depicts the application in a Preview 
mode showing in the left-hand window a plurality of files as well as the file Messen.jpg 
being highlighted for viewing in the right-hand window (see top Fig,, p. 2; compare with 
Claim 5, "... (a) managing a plurality of data files with a host application, the host 
application supporting applet execution; (b) selecting a data file from a plurality 
of data files"). Hackbarth does not specifically teach (c) analyzing the data file for the 
presence of data of a first type and a second type. However, it would have been 
obvious to one of ordinary skill in the art at the time of invention because such an action 
typically occurs in reading files having plural types of data. The benefit would have been 
to determine the file type and to be able to apply the necessary code steps to read and 
load the file. Hackbarth does not specifically teach (d) processing data of the first type 
through a first applet and data of the second type through the second applet However, 
it would have been obvious to one of ordinary skill in the art at the time of invention to 
read and extract the two file types using distinct coding portions, whether those coding 
portions are separate programs (applets), or part of a larger single program (applet or 
standalone application) because it is well known in the programming art to do so. In 
addition, Microsoft Press defines an applet as a small piece of code that can be 
transported over the Internet and executed on the recipient's machine. The term is 
especially used to refer to such programs as they are embedded in line as objects in 
HTML documents on the World Wide Web (see p. 27). The benefit of an applet being 
small allows it to download to the client more quickly, taking less storage space, and 
likely requiring smaller processing resources. Hackbarth does not specifically teach (e) 
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merging and formatting the processed first and second data within the host application. 
However, it would have been obvious to one of ordinary skill in the art at the time of 
invention to assume that this would have occurred because it is what one would have 
expected as part of the viewer programming as a necessary step to produce a display 
of the file contents. Hackbarth does teach displaying the file contents (see Figs. Pp. 1- 
3; compare with Claim 5, "... (f) displaying the merged and formatted processed 
first and second data"). 

Claims 6-10, and 14-18 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Hackbarth in view of Microsoft Press and in further view of Adobe 
("TIFF, Revision 6.0 Specification", Copyright 06/03/1992, Adobe Developers 
Association). 

In regard to dependent Claim 6, Hackbarth fails to teach that the first data type is 
a graphics type and a second data type is a text data type. However, Adobe teaches 
the TIFF 6.0 file format standard containing a header portion and a tag portion (both 
text), and a portion for the graphics file (specifically a Bilevel image) (see p. 20). It 
would have been obvious to one of ordinary skill in the art at the time of invention to 
combine the teachings of Hackbarth, Microsoft Press, and Adobe, because they all 
describe aspects of manipulating mixed content files with the goal to load and display 
such files in an efficient and convenient manner. 
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In regard to dependent Claim 7, Hackbarth teaches that the applet can read 
Tagged Image File Format (TIFF) files that contain as part of their content Tags (see p. 
1 ; compare with Claim 7, "... the data file comprises a tagged format"). 

In regard to dependent Claim 8, Hackbarth fails to teach that the first data type 
comprises a compressed format image. However, Adobe teaches TIFF version 6.0 
standard for storing images. One feature of the TIFF format is its ability to accept 
multiple types of compression schemes for the images (see pp. 30-31 ). It would have 
been obvious to one of ordinary skill in the art at the time of invention to combine the 
teachings of Hackbarth, Microsoft Press, and Adobe, because they all describe aspects 
of manipulating mixed content files with the goal to load and display such files in an 
efficient and convenient manner. 

In regard to dependent Claim 9, Hackbarth fails to teach that the data file 
comprises: a header portion containing an index portion. However, Adobe teaches a 
header portion containing an offset location (index) for the first IFD, a tag portion 
containing an offset location (index) for the next IFD. Both of these positions containing 
the offset location are at the end of the header and tagged portions respectively (see 
table p. 20). Hackbarth also fails to teach that a first data type located near a terminus 
of the data file at a starting location referenced by the index portion. However, Adobe 
teaches an Image Data portion with a starting location near the end of the file, with the 
end of the Image Data portion at the end of the TIFF file. The index identifying the 
location of the Image Data portion lies at the end of the regular tagged portion (see 
table p. 20). Hackbarth also fails to teach a second data type located between the 
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header and the first data type, having an end of file marker at its terminus. However, 
Adobe teaches that the tagged portion (containing text) is located between the header 
portion and the Image Data portion (see table p. 20). Adobe does not teach that an end 
of file marker exists at the end of the second data type. However, it would have been 
obvious to one of ordinary skill in the art at the time of invention to place and end of file 
marker at the end of any of the portions contained in the TIFF file format because it was 
common practice to do so, especially when similar files with mixed text and binary 
contents were written to 9-track tape or other linear fashion. The benefit would have 
been to identify different portions of the file, as well as to identify the end of a file. 

In regard to dependent Claim 10, Hackbarth teaches that Tiffy View can be used 
as an applet from an HTML web page. On the client side only a Java capable web 
browser like Netscape Navigator (version 3 or higher), Microsoft Internet Explorer 
(version 3.02 or higher) (see p. 4, 2 nd paragraph; compare with Claim 10, "... the host 
application comprises a hypertext browser"). 

In regard to independent Claim 14, Hackbarth teaches that Tiffy View can be 
used as an applet within a web page on a web browser where files can be read and 
data extracted (see p. 5). Hackbarth does not specifically teach using separate applets 
to read and extract both a graphics type and a text data type in the same file. However, 
it would have been obvious to one of ordinary skill in the art at the time of invention to 
read and extract the two file types using distinct coding portions, whether those coding 
portions are separate programs (applets), or part of a larger single program (applet or 
standalone application) because it is well known in the programming art to do so. 
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Microsoft Press defines an applet as a small piece of code that can be transported over 
the Internet and executed on the recipient's machine. The term is especially used to 
refer to such programs as they are embedded in line as objects in HTML documents on 
the World Wide Web (see p. 27). The benefit of an applet being small allows it to 
download to the client more quickly, taking less storage space, and likely requiring 
smaller processing resources. Hackbarth fails to teach that the data file includes an 
index portion in a header pointing to the first data type, and the second data type 
resides between the header and the first data type, having an end of file marker at a 
terminus thereof However, Adobe teaches a header portion containing an offset 
location (index) for the first IFD, a tag portion containing an offset location (index) for the 
next IFD. Both of these positions containing the offset location are at the end of the 
header and tagged portions respectively. Adobe also teaches an Image Data portion 
with a starting location near the end of the file, with the end of the Image Data portion at 
the end of the TIFF file. The index identifying the location of the Image Data portion lies 
at the end of the regular tagged portion. Adobe also teaches that the tagged portion 
(containing text) is located between the header portion and the Image Data portion (see 
table p. 20). Adobe does not teach that an end of file marker exists at the end of the 
second data type. However, it would have been obvious to one of ordinary skill in the 
art at the time of invention to place and end of file marker at the end of any of the 
portions contained in the TIFF file format because it was common practice to do so, 
especially when similar files with mixed text and binary contents were written to 9 track 
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tape or other linear fashion. The benefit would have been to identify different portions of 
the file, as well as to identify the end of a file. 

In regard to dependent Claim 15, Claim 15 reflects the method of processing a 
data file having two different data types as claimed in Claim 14, and is rejected along 
the same rationale. 

In regard to dependent Claim 16, Hackbarth teaches a platform independent 
application (written in Java) to view and print images of the following formats: TIFF, 
kMP, GIF, JPG, and PNG (called Tiffy View). Additionally, Hackbarth teaches that it is 
usable as a standalone application or, alternatively the program can be run as a Java 
applet in any Java capable web browser to extend standard internet/intranet technology 
with a powerful component for electronic document management (see page 1). 
Hackbarth does not specifically teach invoking the first and second applets for 
interpreting the composite data. However, it would have been obvious to one of 
ordinary skill in the art at the time of invention to assume that the applet was invoked by 
downloading the file from the browser, as this is its function as a viewer for various file 
types including TIFF. Reading the file using two separate applets, or one applet with 
two classes would not matter. The benefit would have been that an applet was 
performing the reading and viewing of the file assuming the graphics viewer was 
browser-based. 

In regard to dependent Claim 17, Hackbarth fails to teach that the first data type 
is a graphics type and a second data type is a text data type. However, Adobe teaches 
the TIFF 6.0 file format standard which depicts a header portion, a tag portion, and a 
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portion for the graphics file (see table p. 20). It would have been obvious to one of 
ordinary skill in the art at the time of invention to combine the teachings of Hackbarth, 
Microsoft Press, and Adobe, because all are related to TIFF format files. The benefit 
would have been to provide an accepted format scheme for describing mixed format 
files. 

In regard to dependent Claim 18, Hackbarth fails to specifically teach that the 
header and first data type are compatible with the Group 4 Tagged Image Format File 
specifications. However, Adobe teaches the format of a TIFF version. 6.0 file 
(specifically a bilevel graphics file) (see table p. 20). It would have been obvious to one 
of ordinary skill in the art at the time of invention to combine the teachings of Hackbarth, 
Microsoft Press, and Adobe, because all are related to TIFF format files. The benefit 
would have been to provide an accepted format scheme for describing mixed format 
files. 
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Conclusion 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to James H Blackwell whose telephone number is 703- 
305-0940. The examiner can normally be reached on Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Joseph H Feild can be reached on 703-305-9792. The fax phone number 
for the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 



James H. Blackwell 
08/06/04 




